Fundamentally, there are two ways to build web applications. One approach is to build HTML pages by assembling together HTML text and sending the resulting text back to the client browser for rendering. The second approach, known as the Single Page Application (SPA) uses JavaScript code running on the client browser to manipulate the Document Object Model (DOM) directly in the browser. The current application improves upon the SPA model.
The majority of existing web application frameworks in the SPA space work entirely on the client side (for example, Client-only Ajax) and provide little support for the server side, leaving the implementation of the server logic to various server side technologies designed for the HTML approach.
Existing user interface libraries, or JavaScript User Interface libraries (for example: jQueryUI, Sencha ExtJS, Telerik KendoUI, ComponentOne Wijmo, Dojo, Qooxdoo, and others) are directed towards the creation and manipulation of the widgets in the client's browser. The lack of widget support (state logic, event handling, tracking and updating properties) on the server requires software developers to write the bulk of their application code in JavaScript and for the client's browser, which can be repetitive and time-consuming.
For example, a web application as shown in FIG. 1 takes as input from a user a social security number and a retirement date, and then calculates the monthly benefits at the specified date. The server executes the logic and calculations, which can involve external services provided by other systems. For example, the server can access an external database to cross reference the social security number to decide what benefits are available to the individual. The server can also access another external lookup table to cross reference how much the individual is entitled to based on date and the type of benefits the individual is allowed. Finally, the server can perform internal calculations to verify that the calculated monthly benefits make sense and are not out of bounds.
The developer would write code for the client: two input text fields 002, button 004, event handling logic for a button press, and updating of the output text field 006. Next, the developer would write code on the server: to detect the request name and route to the handler, to read and validate the arguments, to service/handle the input data (e.g. a routine to calculate the benefits based on an input SSN and Date from the client), to manage errors, and to format the response.
Table 1 shows an example of code (in pseudocode) that a developer generally writes on the client-side, to implement the simple web application shown in FIG. 1:
TABLE 1var textBoxSSN = new TextBoxWidget({  placeholder: “Enter your SSN”});var textboxDate = new TextBoxWidget({  placeholder: “Enter the retirement date (MM/YYYY)”});var submitButton = new ButtonWidget({  text: “CALCULATE BENEFITS”,  clickHandler: submitButton_onClick});function submitButton_onClick( ) {  AjaxRequest.send({    serviceName: “calculateBenefits”,    serviceArgs:[      “SSN=” + textBoxSSN.getValue( ),      “Date=” + textBoxDate.getValue( )    ],    result: calculateBenefits_onResult;  }}function calculateBenefits_onResult(data) {  // code to display the result, or error messages, to the user.  // code to check and display potential errors is omitted for simplicity.  this.labelPayment.setValue(data.monthlyPayment);}The pseudocode in Table 1 is simplified, as it does not account for other client side code such as: 1) validation, 2) formatting, 3) adding the controls to a form on the page, 4) managing the layout of the widgets, 5) displaying feedback to the user while the server is processing the request, 6) saving display and state information for browser refresh, or 7) displaying the result or an error message.
Similarly, the simplified service definition to calculate the benefits, can be written like this:
TABLE 2public void calculateBenefitsService(HttpContext context) {string ssn = context.Request[“SSN”];string date = DateTime.Parse(context.Request[“Date”]);double amount = PerformBenefitsCalculation(ssn, date);context.Response.Write(amount);}The code snippet in Table 2 above ignores additional “plumbing” code on the server side, such as: 1) detecting the request name and route it to the handler, 2) reading and validating the arguments, 3) managing errors, or 4) formatting the response.
In comparing this simple web application of FIG. 1, only having 2 input fields and 1 button, to a real life line of business (LOB) application with hundreds of input fields, dozens of buttons and actions on the same page, data requests and field updates that need to occur at any time, nested lookups and data entering (e.g., search or add a customer while filling a complex form without leaving the form), it becomes apparent that the currently available web application technologies require developers to write enormous amounts of code to manage the layout, data entering, validation, service requests, response handling, User Interface (UI) updates, state management, security and authentication, nested workflow, and more.
This disclosure provides a system of managing a client and server that are in live sync with each other, without requiring any additional coding, and allows developers and designers to build user interfaces of any visual complexity.
The example application in FIG. 1 created using the methods of this disclosure allows the developer to write only the code that focuses on the actual problem, calculating the benefits. Everything else is managed by the framework: middleware that implements the methods and techniques discussed herein.
The code in Table 3 below (in pseudo-code) is all that a developer would be required to write for an application under the disclosed method. The code runs entirely on the server and interacts with the server-side representation of the client-side widgets. The middleware, running on the client and in the server, marshals any changes and inputs in the browser to the server, performs any action request by the user (e.g. button click), and updates the client in real-time.
TABLE 3private void calculateButton_Click( ) {string ssn = this.textBoxSSN.Text;string date = this.datePickerDate.Value;double amount = PerformBenefitsCalculation(ssn, date);this.labelPayment.Text = amount.ToString( );}Furthermore, with regard to modal execution, web applications built with existing technologies emulate modal execution only on the client side. This requires the code flow to save the state, exit, and then resume later in response to user actions. The result is a limited and cumbersome architecture that is prone to errors and difficult to manage. Moreover, the field is lacking in a standard way to handle modal workflows and all the techniques implemented in the various web application frameworks deal only with the UI aspect of the modal state.